Canonical issue

Fixes #1158

Outcome

The Secret Scan / gitleaks (working tree) job stops failing on every pull
request in the repository.

gitleaks flags one line of uv.lock that contains no secret:

Finding:     30/4b/90c937815137d43ce71ba043cd3566221e9df6b9c805f24b5d138c9d40a7
Rule:        square-access-token
File:        uv.lock
Line:        5129
Entropy:     3.884

That string is the PyPI content-hash path segment of the parso 0.8.7 sdist URL.
It is high-entropy by construction and matches the square-access-token
pattern by coincidence. Because uv.lock is committed and unrelated to any
individual change, every PR inherits the failure — the job has been red
repo-wide, which is the worst possible state for a secret scanner: a check
nobody can distinguish a real finding in.

After this change the scan reports no leaks found on a clean tree, so a
future red result is signal again.

Scope

• Included: a narrowly targeted allowlist entry in .gitleaks.toml, and a test
  that pins the properties which make it narrow.
• Explicitly excluded: uv.lock itself (unchanged), the gitleaks version pin,
  .github/workflows/secret-scan.yml, and the default rule set — useDefault
  stays on.

What was deliberately not done: the obvious fix is
paths = ['''uv\.lock''']. That is wrong. A uv lockfile can legitimately carry
a private index URL with inline credentials
(https://user:token@pypi.internal/simple/...), which is exactly the leak this
job exists to catch. Excluding the file by path would blind the scanner to the
one real secret it is most likely to find there. The allowlist is therefore
anchored to the benign pattern instead of to the file.

Risk

• Risk level: low, but it is a change to a security control, so the narrowness
  matters more than the size of the diff.
• Failure mode: an over-broad allowlist that suppresses a genuine secret. Two
  properties bound it, and both are asserted by tests: the regex is anchored to
  the literal host https://files\.pythonhosted\.org/packages/, so it cannot
  match a credential on any other host; and it is a regexes entry, not a
  paths entry, so no file is ever wholly exempt.
• Rollback: revert this commit. The scanner returns to its previous behaviour —
  which is to say, red on every PR again.

Note on gitleaks semantics that shaped the implementation:

• The pinned version is 8.18.4, which supports only a single [allowlist]
  block. [[allowlists]] with condition = "AND" arrived in 8.19. paths and
  regexes are therefore OR-ed and cannot be AND-combined, which is a second,
  independent reason the entry had to be pattern-anchored rather than
  path-plus-pattern.
• regexTarget = "line" is load-bearing. The extracted secret is the bare hex
  segment and contains no host at all, so a host-anchored regex only matches
  when evaluated against the whole source line. Without it the allowlist
  silently does nothing.

Verification

Reproduced and verified with the same gitleaks version CI pins, 8.18.4,
installed locally, using the same command as the workflow
(gitleaks detect --no-git --config .gitleaks.toml --redact --verbose --exit-code 1):

before:  leaks found: 1
after:   no leaks found

Negative test — the part that matters. A suppression that merely makes the
scan green is worthless. To prove the allowlist is scoped to the benign pattern
and not to the file, the offending line was duplicated into uv.lock with the
host swapped to pypi.internal.example.com:

still flagged: leaks found: 1

The scanner still catches a same-shaped, high-entropy string on a different
host inside the very file being allowlisted. That is the property that would
have been destroyed by a path exclusion.

tests/unit/test_secret_scan_config.py — 5/5 pass
(PYTHONPATH=. python3 -m unittest tests.unit.test_secret_scan_config). It
asserts: useDefault remains enabled; no lockfile is path-allowlisted; the
regex retains both the host anchor and the /packages/ prefix; regexTarget
is line; and secret-scan.yml still passes --config .gitleaks.toml so the
config is actually consulted.

Mutation-tested three ways, each applied, run, and reverted:

CAUGHT   blanket uv.lock path exclusion
CAUGHT   host anchor removed from the regex
CAUGHT   regexTarget dropped (allowlist becomes inert)

• Focused tests
• Required CI — gitleaks (working tree) and agent-completion/truth-gate both pass on this head
• Review threads resolved

Agent completion enforcement is red here, as it is on every open PR in the
repository, because its trust policy is unprovisioned. Surveyed and tracked
separately in #1160; it is unrelated to this diff.

Production evidence

Not applicable: no runtime surface changes. The diff is one CI configuration
file plus its test; no application code, dependency, or infrastructure is
touched, and uv.lock is byte-identical.

The evidence for a scanner change is the scanner's own behaviour, which is why
verification above is a real 8.18.4 run at the pinned version rather than a
reimplementation of the rule, and why it includes a negative case proving the
suppression still fails closed on a different host.

Notes for reviewers

Recommend merging this first of the currently open fixes. It unblocks the
secret scan for every PR in the repository, including #1154 and #1155, which are
cut from a main that predates it and stay red on this check until it lands.

Agent handoff

• One canonical issue is linked
• No competing PR implements the same issue
• Acceptance criteria are satisfied
• Required checks pass on the current head
• Human decision is requested only for product, security, irreversible infrastructure, or production approval